EKSをDome9で監査してみました

EKSをDome9で監査してみました

Clock Icon2020.03.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんばんわ、札幌のヨシエです。

先日、EKSのコストが半額になってEKSクラスターを作った方が爆増している中、EKSが安全に使用されるのか心配になる方もいらっしゃると思います。 今回はEKSを使用する心理的安全性を下げるためにDome9を使って監査をやってみたので共有します。

前提条件

Dome9の監査用Agentはクラスター上にPodとしてデプロイされます。 エージェントは以下のバージョンをサポートしてます。

事前準備

EKSクラスター作成

# eksctl create cluster \
--name dome9-eks-cluster \
--version 1.14 \
--region ap-northeast-1 \
--nodegroup-name standard-workers \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 3 \
--ssh-access \
--ssh-public-key hogehoge \
--managed

確認コマンド

kubernetes

kubernetesバージョン:v1.12以降

% kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11:23:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.9-eks-502bfb", GitCommit:"502bfb383169b124d87848f89e17a04b9fc1f6f0", GitTreeState:"clean", BuildDate:"2020-02-07T01:31:02Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Helm

Helm:v3.0以降

% helm version
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

Dome9 APIキーを発行する

AgentをデプロイするためにはAPIキーの発行が必要なりますので、以下の手順でAPIキーを作成します

  1. SETTINGSを選択
  2. Credentialsを選択
  3. APIキーの作成を選択

※私の失敗した点で「APIキーの作成」によって作成された後にNameにて使途を記載する形が良いです、後からこのAPIキーを作成したのが自分かわからなくなりました。

エージェントをデプロイするための準備

Dome9でアセスメントを行うためにエージェントをデプロイします。

以下の手順を実行します。

  1. ASSET MANAGEMENTを選択
  2. OnBoardingを選択
  3. Get started with Kubernetesを選択

各種情報を入力します。

  • Kubernetsクラスター名を入力
  • 先程作成したAPIキーを選択
  • エージェントを導入するネームスペース名を入力

必要情報の入力後に「NEXT」を選択します。

以下のように上記で入力した情報を元にHelmでデプロイするコマンドが組み立てられますので、

コマンドラインから実行します。

※この時点で管理アセットには入力されたk8sクラスター名が登録されますので注意しましょう

コマンド実行後、以下のような出力が行われます。

% helm install asset-mgmt checkpoint/cp-resource-management --set-string credentials.user=hogehoge --set-string credentials.secret=hugahuga --set-string clusterID=hogehugahogehuga
NAME: asset-mgmt
LAST DEPLOYED: Thu Mar 12 18:26:49 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
For further actions please visit https://secure.dome9.com/

Pod状態を確認して、ステータスがRunningになればデプロイ完了となります。

% kubectl get pods
NAME                                                 READY   STATUS    RESTARTS   AGE
asset-mgmt-cp-resource-management-78df598666-sslnq   1/1     Running   0          29m

アセスメントを実行

次にアセスメントを実行してみます。

  1. POSTURE MANAGEMENTを選択
  2. Compliance Rulesetsを選択
  3. CIS Kubernetes Benchmark v1.4.0を選択

アセスメント対象を選択する画面が表示されるので、今回設定を行ったKubernetesクラスターを対象に選択して「RUN」を選択します。

アセスメント実行結果は以下のようになります。

体感では1,2分程度でアセスメント結果が表示され、見やすいUIが表示されました。

アセスメント内容を見てみる

一部監査でFailedした内容を確認してみます。

以下はコンテナをroot権限で実行することが許可されていることで出力されました。

通常であれば対処方法は別で調査しなければならないところですが、Dome9では具体的な修正内容のヒントをくれるので対応に困ることは少なくなりそうです。

最後に

今回はKubernetes環境に対してDome9でセキュリティアセスメントを実施してみました。

終盤で書いてあるようにどのような課題があるかを見つけることは多くの製品であると思いますが、

解決の方向性を示してくれる点から優れた製品という印象を受けました。

豆情報(今回の検証で出力されたエラーメッセージ)

かなり初歩的で恐縮ですが検証対象をEKSで使用してみました。

検証を進める際にkubectlを実行すると以下の出力メッセージが出ました。

error: You must be logged in to the server (the server has asked for the client to provide credentials)

最初はなんのことかと思いましたが、AssumeRoleの期限切れでアクセスが出来なかったことで出力されたログのようです。もし同じようなメッセージが表示されましたら以下のコマンドで触ってるIAMユーザー or IAMロールを確認してみてください。

# aws sts get-caller-identity

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.